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Method of generating charging data in a data network, and a 
data network 

FIELD OF THE INVENTION 

[0001] The invention relates to a method of generating charging 
data in a data network, and to a data network. 

BACKGROUND OF THE INVENTION 

[0002] A data network refers herein to both the conventional TCP/IP 
protocol-based Internet and a mobile system employing the wireless applica- 
tion protocol (WAP), as well as to third-generation mobile systems, for instance 
the UMTS (Universal Mobile Telecommunications System), including their 
Internet connections. The services of the data network can be used by utilising 
both the conventional Internet technology and the WAP technology. The Inter- 
net is a worldwide, TCP/IP-based open data network. When taken expansively, 
the Internet includes the intranet, which is an internal data network of an or- 
ganisation, and the extranet, which is an inter-organisational data network in- 
tended for a restricted group of users. They, too, employ the TCP/IP protocol 
and the Internet, in its narrow sense, is generally utilised in their implementa- 
tion. WAP is a protocol specification, by means of which subscriber terminals 
in a mobile system can use services provided on the Internet, intranet or extra- 
net, which in this context are called WAP services. Third-generation mobile 
systems refer to advanced digital, broadband network-based systems intended 
for worldwide use. One such system is the European UMTS based on 
WCDMA (Wideband Code Division Multiple Access) technology. 

[0003] Internet services are typically used through a telecommuni- 
cations connection provided by an Internet connection provider and a server 
used for the connection. WAP services are typically used through a WAP 
gateway maintained by a WAP connection provider. The term connection pro- 
vider is used herein for both an Internet connection provider and a WAP con- 
nection provider. A connection provider refers herein to an operator providing a 
portal, an operator providing a connection, and an operator providing a charg- 
ing service. 
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[0004] Internet services can be used based on either the conven- 
tional request-response (pull) technology or push technology. In the request- 
response technology, a service request from a subscriber terminal is identified 
at a node of a network system and forwarded to a content server providing the 
requested service, after which response data generated in the content server 
on the basis of the service request is forwarded to the subscriber terminal. In 
the push technology, a server transmits data to a subscriber terminal on the 
basis of a request made once by the user without a transmission request re- 
lated to an individual transmission. WAP services are today used mainly by 
employing the request-response technology, but services based on the push 
technology are also being introduced for a wider use. If required, further infor- 
mation can be found on the home page of WAP Forum working on the WAP 
specification at http://www.wapforum.org. 

[0005] Billing for the use of WAP services is typically based on the 
connection time used for data transmission. If the bi-directional data transmis- 
sion connection between the subscriber terminal and network part of a mobile 
system is a circuit-switched connection, for instance a data call connection, 
connection time-based charging is a natural charging method. The problem 
with this is that it is difficult to divide the billed amount of money between the 
different services or service entities used during a specific connection time. 

[0006] Billing for the use of Internet services is typically based on an 
agreement signed between the user and the content provider, on the basis of 
which a fixed monthly charge, for instance, is defined for the use of the service. 
In addition, the connection provider charges the user for the used telecommu- 
nications connection according to a separate agreement. A problem with this 
system is for instance that the user needs to sign agreements with several dif- 
ferent parties to be able to use different service entities and the Internet con- 
nection. 

[0007] Billing can also be based on the number of data packets 
transmitted through a packet-switched connection. If the telecommunications 
connection between the subscriber terminal and network part of the mobile 
system is a packet-switched connection, for instance a connection using a 
short message service (SMS), packet-switched data service, i.e. GPRS (Gen- 
eral Packet Radio Service), or UMTS, charging can be done on the basis of 
the number of the transmitted packets. A drawback of this method is that it is 
difficult to combine service events belonging to one service entity but provided 
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by different content providers and, on the other hand, to distinguish them from 
the service events provided by different content providers. Another problem is 
that the use of one and the same service may require a different number of 
transactions in different subscriber terminals. In such a case, the users of dif- 
ferent subscriber terminals pay a different price for the same service entity 
when the charging is done on the basis of the number of data packets. 

[0008] For WAP-service billing, event-based charging methods, 
based on identifying transactions, i.e. individual service events of a service 
entity, have also been developed. In the request-response technology, a 
transaction is one request-response pair. A method based on analysing an 
URL address has earlier been used as such an event-based system, in which 
the transactions belonging to a given service entity are identified and one of 
the transactions is selected for charging. A problem with this method is that the 
transactions related to one service entity cannot be combined, and one of the 
events must be selected as the charged event. In such a case, a problem 
arises from processing error situations and from the fact that the number of 
transactions varies in different subscriber terminals. In an error situation, in 
which the transaction marked for charging fails, the user is not charged at all 
for the use of the service entity. Then again, in a situation, in which the user 
obtains the transaction marked as chargeable but not all transactions belong- 
ing to the service entity, the user is charged for an incomplete service entity. 
Charging in a situation, in which the user interrupts the service, also poses a 
problem. A further problem of the method is that URL address-based charging 
requires a great deal of testing and configuration from the charging system, 
because the URL address of each individual service must be found and con- 
figured for charging. 

BRIEF DESCRIPTION OF THE INVENTION 

[0009] It is an object of the invention to provide an improved method 
of generating charging data in a data network and an improved data network 
implementing the method. As one aspect of the invention, the method for gen- 
erating charging data as claimed in claim 1 is disclosed. As another aspect of 
the invention, the data network as claimed in claim 30 is disclosed. Other pre- 
ferred embodiments of the invention are disclosed in the dependent claims. 

[0010] The invention is based on creating a general-purpose 
method of identifying individual transactions in a service entity and generating 
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from them one content ticket for each service entity so as to be able to identify, 
monitor and charge for service entities based on the content ticket. 

[0011] The invention describes a general method of generating con- 
tent-based charging data of a service entity, so the need for situation-oriented 
solutions and configurations is significantly reduced. The solution is reusable, 
i.e. it can be used in connection with different services and service entities. It 
can be used in both the conventional TCP/IP-based Internet and a data trans- 
mission system employing the wireless application protocol (WAP), as well as 
in third-generation mobile systems, for instance UMTS (Universal Mobile Tele- 
communications System), including their Internet connections. 

[0012] The method and arrangement of the invention are also sys- 
tem or manufacturer-independent, i.e. the node of the used data transmission 
connection - in the case of a system using the wireless application protocol, 
the WAP gateway - need not be the hardware of the same system or manufac- 
turer as that in which the content ticket is generated. 

[0013] A content provider produces service entities whose delivery 
to the user of a subscriber terminal typically requires several separate transac- 
tions. By means of the invention, it is possible to assemble the separate trans- 
actions in a content entity together and to charge for the entire service entity 
instead of individual transactions. Being able to charge for service entities, the 
connection provider is also better able to assign to each different content pro- 
vider its share of the charged amount of money, which often presents prob- 
lems. On account of the invention, the connection provider need not decide 
which transaction to select for charging, contrary to the transaction-based 
charging that was applied before. 

[0014] The content ticket of the invention also enables more versa- 
tile charging rules. If the user of a service entity interrupts its use before receiv- 
ing all parts of the service entity, it is possible to charge for a certain proportion 
of the price of the service entity on the basis of the content ticket. If, as in the 
earlier transaction-based charging method, only one transaction was selected 
from the service entity, on the basis of which the user was charged for the en- 
tire service entity, it would be possible that the user was also charged for parts 
of the service that he did not receive. Or on the other hand, it would be possi- 
ble that the user was not charged at all for the service, if the user did not re- 
ceive the transaction that was selected for charging. On the basis of the con- 
tent ticket, it is also possible not to charge the user for the entire service, if the 
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use of the service entity was interrupted due to reasons beyond the user's con- 
trol. By means of the content ticket, the user can also be charged based on 
how far he has proceeded in the service entity. For instance, if the service en- 
tity the user is using is a game, in which he proceeds to the second level, 
where the game ends, the user can be charged less than if he had not pro- 
ceeded to the second level. 

[0015] Information on the user of the service, such as MSISDN 
(Mobile Subscriber International ISDN Number), or the IP address of the sub- 
scriber terminal, is always attached to the content ticket of the invention. Other 
information is also attached to the content ticket, such as the service URL, the 
name of the service, start and end time, information on the success of the con- 
tent ticket generation, or information on the success of the individual transac- 
tions of the service entity. These enable versatile monitoring and event man- 
agement. 

[0016] In the system of the invention, the connection provider can 
configure the generation rules of the content ticket. This makes it possible for 
the connection provider to create by means of the method a charging and 
monitoring system that exactly corresponds to its needs and the current situa- 
tion. The configuration rules can be created together with the content provider, 
because the content provider can best define which transactions the service 
entity consists of. Configuration also includes the definition of the transactions 
in the service entity that are chargeable, i.e. menus, for instance, can be de- 
fined non-chargeable. 

[0017] The connection provider can define the basis for identifying 
the transactions, from which the content ticket is generated. This can be done 
for instance on the basis of the URL or IP address of the content provider or a 
specific content identifier (content_id) attached to the transaction and defined 
according to the invention. Likewise, the grounds for identifying the transac- 
tions belonging to a content entity of a content provider and to be included into 
the same content ticket are defined. According to the invention, this can be 
done for instance by means of a specific content identifier (content Jd) at- 
tached by the content provider to the transaction. These identifiers can be indi- 
cated in key fields added to the header information, for instance http header 
information, of individual transactions. 

[0018] The connection provider also adds a specific service platform 
identifier (serviceplatform_id) to the content ticket for identifying the service 
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platform and content provider from which the transaction originates. This is 
used to distinguish the contents arriving from different service platforms and 
content providers, because several content providers may use the same con- 
tent identifier space. According to the invention, this can be done in such a 
manner, for instance, that the content provider inserts the service platform 
identifier (serviceplatform_id) to key fields added to the header information, for 
instance http header information, of individual transactions. 

[0019] The use of the content identifier and the service platform 
identifier is clarified by the example in the following table, in which the service 
entity consists of providing a three-frame cartoon to a user of the service. In 
one subscriber terminal, the transmission of the cartoon to the user requires 
thirteen transactions. In the example, each frame comprises three different 
frame elements and the header information of the frame. 



Transaction having URL 


Content identifier 


Service platform identi- 
fier 


Common http header 
info for entire cartoon 


12345 


99999 


Header info for first 
frame 


12345 


99999 


First frame element of 
first frame 


12345 


99999 


Second frame element 
of first frame 


12345 


99999 


Third frame element of 
first frame 


12345 


99999 


Header info for second 
frame 


12345 


99999 


First frame element of 
second frame 


12345 


99999 


Second frame element 
of second frame 


12345 


99999 


Third frame element of 
second frame 


12345 


99999 


Header info for third 
frame 


12345 


99999 
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First frame element of 
third frame 


12345 


99999 


Second frame element 
of third frame 


12345 


99999 


Third frame element of 
third frame 


12345 


99999 



[0020] The content identifier and a possible service platform identi- 
fier can also be transmitted to the connection provider separate from the actual 
transaction data by using a separate signalling channel. In such a case, infor- 
mation on which transaction and subscriber the transmitted identifiers belong 
to must be added to the identifiers. This can be done for instance by transmit- 
ting together with the identifier information a user identifier, for instance 
MSISDN or IP address, and a transaction identifier, for instance by means of a 
separate transaction-specific identifier attached to the transactions and identi- 
fier information, or by transmitting together with the identifier information time 
information, by means of which charging information can be combined with 
status information obtained from the node of the data transmission system, for 
instance the WAP gateway or http proxy server. 

BRIEF DESCRIPTION OF THE FIGURES 

[0021] The invention will now be described in greater detail by 
means of preferred embodiments and with reference to the attached drawings, 
in which 

Figure 1 is a simplified block diagram showing a mobile system em- 
ploying the wireless application protocol as an example of a data network sys- 
tem, 

Figure 2 shows the generation of a content ticket on the basis of 
transactions, 

Figure 3 is a flow chart showing a method of generating charging 
data in a data network. 

DESCRIPTION OF THE EMBODIMENTS 

[0022] Figure 1 shows the application of the method to a mobile 
system employing the wireless application protocol (WAP) that uses the re- 
quest-response technology. The application of the invention is not, however, 
restricted to the case of the example, but the invention can also be applied to 
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other data networks, such as the conventional Internet or third-generation mo- 
bile systems, for instance UMTS. 

[0023] Figure 1 is a simplified general view of a WAP system of the 
invention connected to the network part of a mobile system. The mobile sys- 
tem can be for instance a GSM system, GPRS system, UMTS system or some 
other mobile system employing the wireless application protocol (WAP). 

[0024] As shown in Figure 1, it is possible to establish a data trans- 
mission connection from a subscriber terminal 100 through a public land mo- 
bile network (PLMN) 102 to a node 104 of a data network, in this case a WAP 
gateway 104. A connection is then established from the WAP gateway 104 
through the Internet 106 to a content server 108 of a content provider providing 
the desired service entity. The connection is established on the basis of the 
Internet address of the service, i.e. the WAP gateway 104 has means 144 for 
transmitting a service request 126, 128 sent by the subscriber terminal 100 to 
the content server 108. Correspondingly, the WAP gateway 104 has means 
144 for transmitting response data 130, 132, 134, 136 generated by the con- 
tent provider in the content server 108 on the basis of the service request 126, 
128 to the subscriber terminal 100. The content server comprises means 142 
to receive the service request and to transmit the response data to the WAP 
gateway 104. The WAP gateway 104 and the content server 108 are prefera- 
bly implemented by hardware equipped with a microprocessor, for instance a 
computer with its peripherals, and with the required system and application 
programs. The means 144, 142 are thus preferably computer modules that 
implement the required functionality. The means 142, 144 can be implemented 
for instance in the control part by using processors and their software, whereby 
the functionality of the means is implemented as parts of software, for instance 
program modules. During the design and implementation of the system, the 
distribution of the functions between the software and hardware is determined 
for instance on the basis of the manufacturing costs and the required data 
processing capacity and rate. Some of the functions can be implemented by 
hardware. 

[0025] Even though Figure 1 shows the service requests and re- 
sponse data as packets, such as messages of a short message service, they 
can as well be transmitted over a circuit-switched connection, such as a data 
call. The essential matter is that the traffic can be analysed and the transac- 
tions related to a specific service and service entity can be identified from it. In 
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the example of Figure 1, four response data packets 130, 132, 134, 136 corre- 
spond to two service requests 126, 128 of the user, but other kinds of combi- 
nations are also possible. Thus, there may be one or more service requests 
and responses. This makes it difficult to identify what traffic belongs to which 
service and service entity. 

[0026] Even though the service event in Figure 1 is shown using the 
request-response (pull) technology, it can also use the push technology, in 
which a server transmits data to a subscriber terminal on the basis of a request 
made once by the user without a transmission request related to an individual 
transmission. 

[0027] The method can be applied using both a connection-oriented 
and a connectionless data transmission connection. 

[0028] A billing system 122 is connected to the WAP gateway. The 
billing system comprises a billing unit 124 that further comprises billing means 
148. A charging information system (WAP charging gateway) 1 10 is connected 
to the billing system 122, which depending on the implementation can be a 
separate unit or a part of the billing system 122. It can also be implemented as 
a part of the WAP gateway 104. The billing system 122 can depending on the 
implementation be a separate unit or a part of the WAP gateway 104, or it can 
belong partly to the WAP gateway while a part of the billing system remains 
outside the WAP gateway. 

[0029] The charging information system 110 comprises the follow- 
ing parts: identification means 146 to identify the chargeable transactions 138, 
140 of the chargeable service entity, and means 146 for generating a content 
ticket 224, 226 of the service entity. The identification means 146 and means 
146 for generating the content ticket 224, 226 as well as the billing unit 124 
with its billing means 148 are implemented, like the WAP gateway, as a suit- 
able combination of hardware and software. 

[0030] The connection provider can define when the generation of 
the content ticket 224, 226 is started, how the individual transactions, from 
which the ticket is generated, are identified, how the content ticket is generated 
and what is included in it. A content ticket is not generated from all transactions 
or services, but information on some of the transactions, for instance individual 
transactions, can be forwarded directly to the billing system. The connection 
provider can configure its charging information system 1 10 to decide whether a 
content ticket is generated, based on the identification of the content provider 
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108 or the identification of the transaction 138, 140, for instance. The decision 
to start generating a content ticket 224, 226 can be made based on identifying 
a specific URL or IP address of a content provider with the means 146 and on 
the basis of the address, the transactions are identified to be ones from which 
the content ticket can be generated. 

[0031] When the connection provider decides to start generating the 
content ticket, its charging information system identifies the transactions re- 
lated to the service entity, from which the content ticket is generated. This is 
done by means of the content identifier (content_id) attached to the transac- 
tion, i.e. the same content identifier is attached to the transactions that belong 
to the same service entity. The content identifier is a subscriber-specific and 
session-specific identifier that the content provider 108 attaches with the 
means 142 to each service entity. 

[0032] The connection provider can also configure its charging in- 
formation system 110 to decide whether to start generating the content ticket 
based on identifying the content identifier (content_id) related to a transaction 
with the means 146. If the content identifier is not found, the content ticket is 
not generated. 

[0033] A service platform identifier (serviceplatform_id) related to 
the transaction is also attached to the content ticket by using the means 146. 
With this identifier, it is possible to identify both the content provider and the 
service platform, from which the content is provided. One content provider may 
have several service platforms, from which it provides identical content, it can 
for instance provide the same content entity both as a conventional Internet 
service and as a WAP service, or it can provide the content from several dif- 
ferent content servers. The service platform identifier makes it possible to dis- 
tinguish the different content providers from each other, since several different 
content providers can use the same content identifier space. On the basis of 
the identifier, it is for instance possible to assign to the content provider its 
share of the amount of money charged from the user for the service entity. 

[0034] With the means 142, the content provider 108 can attach the 
service platform identifier (serviceplatform_id) to each transaction of its service 
response. If the content provider does not attach the service platform identifier 
to the transactions, the connection provider can generate it on the basis of the 
URL or IP address of the content provider and attach it to the content ticket by 
using the means 146. Even though the content provider did not attach the 
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identifier to its service, or only attached it to its services arriving from certain 
service platforms, it is in this manner possible to have an identifier describing 
the content provider in the content ticket, and on the basis of the identifier, the 
ticket can be used to assign a charging event and the processing of a bill to 
the service provided by the correct content provider and service platform. 

[0035] The content identifier (content_id) and the service platform 
identifier (serviceplatform_id) can be transmitted by means of the means 142 
to the connection provider in key fields attached to the header information of 
the service response, typically in the key fields of http headers. The identifiers 
can, however, also be transmitted separate from the service response data. 

[0036] The connection provider generates the content ticket on the 
basis of the transaction identification information obtained from the WAP gate- 
way 104. The WAP gateway 104 can generate the required identification in- 
formation as shown in Figure 2 either in such a manner that the WAP gateway 
104B generates with the means 144 one transaction ticket 216, 218 of each 
transaction 200, 202 or the WAP gateway 104A generates with the means 144 
several raw events 208, 210, 212, 214 of each transaction 204, 206. In the 
charging information system 110, these raw events 208, 210, 212, 214 can 
then be generated into a transaction ticket 220, 222 with the means 146. The 
content ticket 224, 226 is generated in the charging information system 1 10 by 
identifying and combining the transaction tickets 216 and 218 or 220 and 222 
belonging to one service entity by means of the content identifier (content_id) 
and the service platform identifier (serviceplatform_id) with the means 146. 

[0037] The connection provider can configure the generation of the 
content ticket as needed. In addition to the required user identifier, typically the 
MSISDN number, content identifier (contentjd) and the service platform identi- 
fier (serviceplatformjd), it is also possible to attach to it for instance informa- 
tion on the success of the ticket generation or information on the success of 
individual transactions, or for instance information on the name of the service 
entity. 

[0038] The finished content ticket of the service entity is used in the 
billing unit 124 to charge for the service entity by means of the billing means 
148. The content ticket can also be used in monitoring and collecting statistics, 
for instance when needing information on the success of the service or when 
examining the functionality of different service entities in different environments 
and terminals. 
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[0039] Finally, the flow chart in Figure 3 shows a method of generat- 
ing charging information in a data network. 

[0040] The method starts from block 300. In block 302, the data of 
the service entity generated by the content provider is transmitted to a node of 
the data transmission connection. In block 304, the data of the service entity is 
transmitted to the subscriber terminal. 

[0041] In block 306, the transactions of the transmitted data are 
identified. This takes place in the node 104 of the data network, in which the 
transaction tickets 216, 218 or raw events 208, 210, 212, 214 are also gener- 
ated. In the next block 308, the identifier information of the identified transac- 
tions, for instance the transaction tickets 216, 218 or raw events 208, 210, 212, 
214, is transmitted to the charging information system 110. 

[0042] In block 310, the chargeable transactions of the chargeable 
service entity are identified. The identification is done by identifying the URL or 
IP address or content identifier as described above and on the basis of the 
identification, a decision is made whether to start generating the content ticket 
or not. When the transaction is identified as one from which a content ticket is 
generated, the transactions belonging to one service entity are always identi- 
fied on the basis of the content identifier and service platform identifier of the 
transaction. Next, in block 312, the content ticket 224, 226 of the service entity 
is generated using the identified transactions. This is preferably done on the 
basis of the content identifier and service platform identifier and by attaching to 
the ticket all other necessary information, such as the user identifier, for in- 
stance MSISDN, and by adding, as described above, other information, such 
as the name of the service or success information as necessary. Finally, in 
block 314, the content ticket of the service entity is used in billing. 

[0043] Even though the invention has been explained in the above 
with reference to examples in accordance with the accompanying drawings, it 
is apparent that the invention is not restricted to them but can be modified in 
many ways within the scope of the inventive idea disclosed in the attached 
claims. 



